[Previous] [Next] [Index]
[Thread]
Requirements document update.
My sincerest apologies for sitting on this for so long. I've appended an
annotated version of the requirements document from the discussions at the
July IETF meeting in Stockholm. I have also started a "WTS documents" page
at,
<http://www-ns.rutgers.edu/www-security/wts-documents.htm>
You can retrieve the original draft, the slides used at the July meeting,
the annotated version (as included here) and a version without the
annotations. EIT's proposal is also listed. I've not linked the page into
the main document tree yet.
Please discuss any changes that need to made to this document on the
<www-security@nsmx.rutgers.edu> mailing list.
Simon Cooper,
Systems Coordinator,
Rutgers University, Network Services.
==============================================================================
INTERNET-DRAFT G. Bossert
Expires XXX, 199n Silicon Graphics Inc.
S. Cooper
W. Drummond
Rutgers University Network Services
October, 1995
Requirements for Web Transaction Security
<draft-ietf-wts-requirements-01.txt>
[This section: "Status of this Memo" was not present on the slides. It is
internet-draft boilerplate]
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. Distribution of
this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other than
as ``work in progress.''
To learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ds.internic.net (US East Coast),
nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
munnari.oz.au (Pacific Rim).
[Slide 1: The working group suggested a one word change to this section. It
has been marked with @{ }]
Abstract
This document specifies the requirements for the provision of security
services to the HyperText Transport Protocol. These services include
confidentiality, integrity, user authentication, and authentication
@{certification} of servers/services, including proxied or gatewayed
services. Such services may be provided as extensions to HTTP, or as
an encapsulating security protocol. Secondary requirements include
ease of integration and support of multiple mechanisms for providing
these services.
[This section: "Introduction" was not present on the slides, I've not edited
it from the original document. Obviously HTTPSec needs to be changed to
something more appropriate. WTS is the name of the group -- should it also
be used when referring to the protocol?]
1. Introduction
The use of the HyperText Transport Protocol [1] to provide
specialized or commercial services and personal or private data
necessitates the development of secure versions that include
privacy and authentication services. Such services may be
provided as extensions to HTTP, or as encapsulating security
protocols; for the purposes of this document, all such
enhancements will be referred to as HTTPSec.
In this document, we specify the requirements for HTTPSec, with
the intent of codifying perceived Internet-wide needs, along with
existing practice, in a way that aids in the evaluation and
development of such protocols.
HTTPSec is an enhancement to an object transport protocol. As
such, it does not provide independent certification of documents
or other data objects outside of the scope of the transfer of
said objects. In addition, security at the HTTPSec layer is
independent of and orthogonal to security services provided at
underlying network layers. It is envisioned that HTTPSec may
coexist in a single transaction with such mechanisms, each
providing security services at the appropriate level, with at
worst some redundancy of service.
[Slide 2: No modifications to this slide were suggested]
1.1 Terminology
This following terms have specific meaning in the context of this
document. The HTTP specification [1] defines additional useful
terms.
Transaction:
A complete HTTP action, consisting of a request from the
client and a response from the server.
Gatewayed Service:
A service accessed, via HTTP or an alternate protocol, by the
HTTP server on behalf of the client.
Mechanism:
An specific implementation of a protocol or related subset of
features of a protocol.
[Slide 3: Most of the discussion revolved around this slide. I have
included the original followed by the suggested replacement. There are
still some outstanding issue with regard to this slide.]
[--ORIGINAL-FROM-DRAFT--]
2. General Requirements
HTTPSec must provide the following services:
o Confidentiality of the HTTP transaction.
o Authentication of the server/service.
o Authentication of the client/user.
o Integrity of the HTTP transaction.
These services must be provided independently of each other.
In addition, HTTPSec should conform to a number of secondary
requirements:
o Ease of integration with other features of HTTP.
o Support of multiple mechanisms for the above services.
These services and additional requirements are discussed in more
detail in the following sections.
[--REPLACEMENT--]
2. General Requirements
WTS must define the following services. These services must be
provided independently of each other.
o Confidentiality of the HTTP transaction.
o Peer entity authentication of the server and/or service.
o Peer entity authentication of the client and/or user.
o Data origin authentication and integrity of the HTTP transaction.
o Non-repudiability of the transaction
o Freshness of integrity and authentication.
o Ease of integration with other features of HTTP.
o Support of multiple mechanisms for the above services.
o Support the needs of proxies and intermediaries
<Allan M Schiffman <ams@eit.com> said he had other issues that should
be here and he would provide. Allan?>
<There was also a request for discussion at what level were multiple
mechanisms to be supported.>
<I also have an action marked for "labeling". I no longer remember what
this was about. I think the issue was raised by the gentleman sitting next
to Allan Schiffman during the working group>
[Slide 4: The note on my slide says to junk this slide]
3. Confidentiality
HTTPSec must provide confidentiality of the HTTP transaction, via
encryption of the HTTP messages.
The entire HTTP transaction must be considered private; thus, the
HTTP headers and data objects of client requests and server
responses must be confidential. Note: because the identity of
the object being requested is potentially sensitive, the URI/URL
of the request should be confidential; this is particularly
critical in the common case of form data or other user input
being passed in the URL.
[Slide 5: The slide contained slightly different text to the original
document, I've marked up the original, the slide and the replacement.]
[--ORIGINAL-FROM-DRAFT--]
4. Service Authentication
HTTPSec must support the authentication of the HTTP server to the
client.
HTTPSec should support the authentication of gatewayed services
to the client.
HTTPSec should support the authentication of the origin HTTP
server or gatewayed services regardless of intermediary proxy or
caching servers.
To allow user privacy, HTTPSec must support service
authentication without user authentication.
Because the identity of the object being requested is potentially
sensitive, service authentication should occur before any part of
the request, including the URI of the requested object, is
passed. In cases where the authentication process depends on the
URI (or other header data) of the request, such as gatewayed
services, the minimum necessary information to identify the
entity to be authenticated should be passed.
[--FROM-SLIDE-5--]
4. Service Authentication
WTS should support the authentication of gatewayed services to the
client.
WTS should support the authentication of the origin HTTP server or
gatewayed services regardless of intermediary proxy or caching servers.
To allow user privacy, WTS must support service authentication without
user authentication.
Because the identity of the object being requested is potentially
sensitive, service authentication should occur before any part of the
request, including the URI of the requested object, is passed. In
cases where the authentication process depends on the URI (or other
header data) of the request, such as gatewayed services, the minimum
necessary information to identify the entity to be authenticated should
be passed.
[--REPLACEMENT--]
4. Service Authentication
WTS should support the authentication of gatewayed services to the
client.
WTS should support the authentication of the origin HTTP server or
gatewayed services regardless of intermediary proxy or caching servers.
To allow user privacy, WTS must support service authentication with
user anonymity.
Because the identity of the object being requested is potentially
sensitive, service authentication should occur before any part of the
request, including the URI of the requested object, is passed. In
cases where the authentication process depends on the URI (or other
header data) of the request, such as gatewayed services, the minimum
necessary information to identify the entity to be authenticated should
be passed.
[Slide 6: The slide contained HTTPSec changed to WTS and a single word
change. The changes are marked as @{ }.]
5. User Authentication
WTS @{HTTPSec} must support the authentication of the client @{user} to
the server.
WTS @{HTTPSec} should support the authentication of the client to
gatewayed services.
WTS @{HTTPSec} should support the authentication of the client to the
origin HTTP server regardless of intermediary proxy servers.
[Slide 7: No changes except for HTTPSec changed to WTS, marked as @{}]
6. Integrity
WTS @{HTTPSec} must provide assurance of the integrity of the HTTP
transaction, including the HTTP headers and data objects of both
client requests and server responses.
[Slide 8: HTTPSec changed to WTS, marked as @{}.
Allan M Schiffman <ams@eit.com> wanted to reword/add text (marked <>)]
7. Integration
In order to support integration with current and future versions
of HTTP, and to provide extendibility and independence of
development, the secure services provided by WTS @{HTTPSec} must be
orthogonal to and independent of other services provided by HTTP.
In accordance with the layered model of network protocols,
WTS @{HTTPSec} must be:
o independent of the content or nature of data objects being
transported
<Allan: reword/add?>
o implementable over a variety of connection schemes and
underlying transport protocols
[Slide 9: HTTPSec changed to WTS, marked as @{}.]
8. Multiple Mechanisms
WTS @{HTTPSec} must be compatible with multiple mechanisms for
authentication and encryption. Support for multiple mechanisms
is required for a number of reasons:
o Accommodation of variations in site policies, including those
due to external restrictions on the availability of
cryptographic technologies.
o Support for a variety of applications and gatewayed services.
o Support for parallel implementations within and across
administrative domains.
To allow interoperability across domains, and to support the
transition to new/upgraded mechanisms, WTS @{HTTPSec} should provide
negotiation of authentication and encryption mechanisms.
[--END-OF-SLIDES--]
[--I've updated this section--]
References
[1] T. Berners-Lee, R. T. Fielding, and H. Frystyk Nielsen.
"Hypertext Transfer Protocol -- HTTP/1.0" Internet-Draft
<URL:gopher://ds1.internic.net/00/internet-drafts/
draft-ietf-http-v10-spec-03.txt>, September, 1995
[2] G. Bossert, S. Cooper, W. Drummond. "Requirements of Secure
Object Transfer Protocols" Internet-Draft
<URL:http://www-ns.rutgers.edu/www-security/draft/
draft-rutgers-sotp-requirements-00.txt>, March 1995.
The revision history of this document can be located at
<URL:http://www-ns.rutgers.edu/www-security/wts-documents.htm>
Acknowledgments
This document is a product of the IETF WTS working group. The working
group uses the wts-wg@nsmx.rutgers.edu mailing list for discussion.
Eric Rescorla of EIT <ekr@eit.com> provided valuable comments on an
early draft of a document called "Requirements of Secure Object
Transfer" [2], a principal influence on this document.
Security Considerations
As noted above.
Author's Addresses
Greg Bossert -- bossert@corp.sgi.com
Silicon Graphics, Inc. MS 15-7
2011 North Shoreline Blvd.
Mountain View, CA 94043-1389
Simon Cooper -- scooper@noc.rutgers.edu
Walt Drummond -- drummond@noc.rutgers.edu
Network Services, Telecommunications Division,
Rutgers University Computing Services
Hill Center, Brett Road, Bush Campus
Piscataway, New Jersey 08855-0879 USA
Voice: 908-445-TDNS
Fax: 908-445-2968